Windows Vista : Introducing Windows Deployment Services

Windows Deployment Services (WDS) replaces the previously named Remote Installation Services (RIS). It is included by default in the upcoming Windows Server 2008, and the functionality can be added to Windows Server 2003 with the Windows Automated Installation Kit (WAIK).

Not just for Windows Vista deployment, WDS supports deployment of the following operating systems:

• Windows Vista

• Windows Server 2008

• Windows XP

• Windows Server 2003

Many administrators that have leveraged Microsoft's Operating System deployment features in the past will have invested to some degree in Remote Installation Services (RIS). WDS replaces RIS and offers a much improved set of features. Knowing that many environments cannot so easily abandon RIS, much work has gone into providing a migration route that can let you continue to leverage your investment in RIS.

1. Replacing Remote Installation Services

WDS and RIS address the same task: the remote deployment of Windows operating systems over the network.

Improvements introduced with WDS include:

• Use of the new file-based imaging format (WIM)

• Use of Windows PE as boot OS

• The ability to deploy both client operating systems such as Windows Vista and server operating systems such as Windows Server 2008

• The ability to send a deployment as a multicast targeting multiple destinations at once instead of sending a separate data stream to each target

There are three functionality modes provided by WDS to better support those moving from a RIS environment. Depending on your selection, you will see different functionality, support for different image file formats, and even a different boot environment. The three available modes are:

• Legacy mode

• Mixed mode

• Native mode

More details on the installation of WDS in Native mode for both Windows Server 2003 and Windows Server 2008 are detailed later in this section, but a brief summary of how to establish each of these modes for WDS is covered in the following sections.

Running WDS in Legacy mode

In Legacy mode, WDS functions just as RIS does. The old OSChooser is the boot operating system, and only RISETUP and RIPPREP images are supported. If you are not going to be deploying Windows Vista, Legacy mode is a perfectly acceptable mode of operation. Key aspects of WDS Legacy mode include:

• Utilization of OSChooser as its boot environment

• Support for RISETUP and RIPREP image types

• The RIS toolset drives the administration experience

To set WDS for Legacy mode, start by installing the RIS component on Windows Server 2003 SP1, install WDS, and then run RISETUP to add an image.

Operating WDS in Mixed mode

In Mixed mode, both boot operating systems are supported (OSChooser and WDS tools). You can use OSChooser to deploy RISSETUP and RIPREP images, and you can deploy WIM files using the WDS management tools. You can choose to boot into RIS or an image containing Windows PE, which gives you excellent support for a RIS and WDS environment. Key aspects of WDS in Mixed mode include:

• Utilization of both OSChooser and Windows PE as their boot environments

• Support for .WIM as well as RISETUP and RIPREP image types

• The RIS toolset and WDS management tools drive the administration experience

To set WDS for Mixed mode, start by installing the RIS component on Windows Server 2003 SP1, then run RISETUP, and add an image. Then install WDS, and then run the following command:

WDSUTIL /initialize-server

Operating WDS in Native mode

In Native mode, WDS may be used to deploy only WIM images. OSChooser and the RIS toolset are not available as they are in the other modes. The WDS management console is used to handle all aspects of WDS management. Key aspects of WDS in Native mode include:

• Utilization Windows PE as its boot environment

• Support for .WIM image types only

• The WDS management tools drive the administration experience

To set WDS for Native mode, start by installing the RIS component on Windows Server 2003 SP1, then install WDS, and then run the following command:

WDSUTIL /initialize-server

2. Reviewing components of Windows Deployment Services

WDS is made up of several services and technologies, some of which are covered in this section to help you become familiar with these key components of WDS, including:

• Pre-Boot Execution Environment (PXE)

• Trivial File Transfer Protocol (TFTP)

• Multicast

• WDS Client

• WDS Management Tools

Understanding the role of the Pre-Boot Execution Environment (PXE)

To avoid the need for boot disks and to eliminate the need for an operating system on client computers, WDS leverages PXE. Most modern computers (network cards) support this technology that allows systems to "boot to the network."

When a PXE boot is initiated, the PXE ROM requests an IP from a DHCP server. As part of the initial DHCP discovery request, the client computer identifies itself as being PXE-enabled, which indicates to the PXE server that it should respond to the client. After the client has an IP address from the DHCP server, the client locates and establishes a connection with the DHCP server to download a network boot image. Based on the choice made, TFTP is used to download a Windows PE image that serves as the operating system for the WDS client.

Understanding the role of the Trivial File Transfer Protocol (TFTP)

TFTP is used to download files needed by the network boot process provided by PXE. The TFTP server downloads files, such as Pxeboot.com, Wdsnbp.com, Bootmgr.exe and default.bcd as well as the full boot image that contains Windows PE. With Windows Server 2008, TFTP download performance has been enhanced to provide faster uploads and downloads of WDS images.

Understanding the role of multicast

Windows 2008 introduces multicast support that is leveraged by WDS to handle the deployment of an image to many computers simultaneously without bogging down the network. When you send an image with a multicast transmission, the data is sent over the network only once for all the computers being targeted, as shown in Figure 1.

The multicast broadcast is a rotating broadcast of file streams that continues to broadcast until every client computer's needs have been met. What this means is that it doesn't matter when clients come online, they can join in on the multicast data at any time in the transfer. Each client listens to the WDS server, and when it has completed sending the image file, it starts over from the beginning. So, if a client misses a file, it can pick it up when the file is sent again the next time. Once all clients have received the entire image file, the multicast session is terminated.

Figure 1. Understanding multicast

The WDS management tools enable you to monitor real-time transmission progress to clients, and even remove clients from the transmission, and also provide logging and reporting features.

Understanding the role of the WDS Client

WDS Client is a graphical wizard that runs under Windows PE. It is used to capture and apply images from the WDS server. This can be interactive (by default) or it can be configured to run in a fully unattended fashion. The Windows Deployment Services client unattend file uses the Unattend.xml format, and it is stored on the WDS server in the \WDSClientUnattend folder. It automates the WDS client user-interface screens (such as entering credentials or specifying an Install image).

Understanding the role of the WDS Management tools

WDS Management tools are a set of tools that may be used to manage the server, operating system images, and client computer accounts. It consists of the WDS Console (an MMC Snap-In) and WDSUtil, which is the WDS Management command line utility. WDSUtil is just as capable (if not more so) than the WDS Console when it comes to managing WDS. For a list of commands supported by WDSUtil, see Table 1.

NOTE